Extendible Process Directory Model

ABSTRACT

A method includes using a computer to derive a design stage directory model based on a core directory model, using the computer to derive a production stage directory model based on the core directory model, adding an extension to one of the models including an activation flag to activate the extension, and saving the models and extension to a computer readable storage device.

BACKGROUND

Businesses today use enterprise software systems to realize aspects ofthe business, such as everyday operations, controlling, reporting, humanresources management, and so on. Activities of the business are modeledin the system and employees perform their tasks in the system.Enterprise software systems are implemented in the informationtechnology landscape of a company within complex projects usually overthe course of months or years. Projects may have several differentstages, for example, design, implementation, upgrade, maintenance, andso on.

In each of these stages, objects that build up the system are copiedfrom one stage to the next and are modified in the next stage accordingto the requirements of the system. As objects are modified in differentproject stages, there may be a need to track and compare the content ofan object from one project stage to the content of an object in anotherproject stage. Also, there may be a need to apply the content of anobject in one project stage to the content of the object in anotherproject stage. While models are used to facilitate tracking of objects,the models may contain attributes that are hard coded, and can be quiteinflexible.

SUMMARY

A method includes using a computer to derive a design stage directorymodel based on a core directory model, using the computer to derive aproduction stage directory model based on the core directory model,adding an extension to one of the models including an activation flag toactivate the extension, and saving the models and extension to acomputer readable storage device.

In one embodiment, a core directory model has a top level, andsuccessive scenario level, process level, and process step levels. Anextension to add a sub-node level beneath the process step level, thesub-node level identities a sender object type and a receiver objecttype (also referred to as parent/child object types), a cardinality, andan exclude flag to provide an option to hide an existing relation orobject type via an extension in the sub-node level.

A system includes a programmed computer system having a module toprovide an extension to a core directory model, the core directory modelhaving a top level, and successive scenario level, process level, andprocess step level, wherein the extension adds a sub-node level beneaththe process step level. The programmed computer system further includesa module to provide an extension to a design stage directory model and aproduction stage directory model, each derived from the core directorymodel and complying with selected compatibility criteria to facilitatetransfer of instances based on the two models.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a life cycle of a processaccording to an example embodiment.

FIG. 2 is a core directory model illustrating grouped scenariosaccording to an example embodiment.

FIG. 3 is a block diagram of models an model based environmentsaccording to an example embodiment.

FIG. 4 is a block diagram illustrating models and environments utilizedto facilitate life cycle management according to an example embodiment.

FIG. 5 is a block diagram of models and model based environments withextensions according to an example embodiment.

FIG. 6A illustrates a top level of a core directory model according toan example embodiment.

FIG. 6B illustrates a scenario sub-structure of a core directory modelaccording to an example embodiment.

FIG. 6C illustrates how a list of scenarios in a scenario group isdefined in a core directory model according to an example embodiment.

FIG. 6D illustrates how a list of process steps within a process stepgroup is defined in a core directory model according to an exampleembodiment.

FIG. 6E illustrates object type and attribute type relations in a coredirectory model according to an example embodiment.

FIG. 7A illustrates a customer process directory model extension of thecore directory model according to an example embodiment.

FIG. 7B illustrates a top level folder of a customer process directorymodel extension of the core directory model according to an exampleembodiment.

FIG. 8 is a user interface illustrating a sample instance based on acore directory model according to an example embodiment.

FIG. 9 is a user interface illustrating a sample instance based on acustomer process directory model extension of the core directory modelaccording to an example embodiment.

FIG. 10 is a user interface illustrating an extension of the coredirectory model according to an example embodiment.

FIG. 11 is an interface illustrating a sample instance based on anextension of the core directory model according to an exampleembodiment.

FIG. 12 is an interface illustrating activation and layering ofextensions to a directory model according to an example embodiment.

FIG. 13 is a user interface illustrating an extension for an objecttype-attribute type relation according to an example embodiment.

FIG. 14 is a user interface illustrating a model extension with a majorstructure change according to an example embodiment.

FIG. 15 is an example computer system having programming instructionstored on a machine readable storage device for cause the computersystem to execute the methods and models according to an exampleembodiment.

DETAILED DESCRIPTION

In the following description, reference is made to the accompanyingdrawings that form a part hereof, and in which is shown by way ofillustration specific embodiments which may be practiced. Theseembodiments are described in specific detail to enable those skilled inthe art to practice the invention, and it is to be understood that otherembodiments may be utilized and that structural, logical and electricalchanges may be made without departing from the scope of the presentinvention. The following description of example embodiments is,therefore, not to be taken in a limited sense, and the scope of thepresent invention is defined by the appended claims.

The models, interfaces, functions, and algorithms described herein maybe implemented in software or a combination of software and humanimplemented procedures in one embodiment. The software may consist ofcomputer executable instructions stored on computer readable media suchas memory or other type of computer readable storage devices. Further,such functions correspond to modules, which are software stored onstorage devices, hardware, firmware or any combination thereof. Multiplefunctions may be performed in one or more modules as desired, and theembodiments described are merely examples. The software may be executedon a digital signal processor, ASIC, microprocessor, or other type ofprocessor operating on a computer system, such as a personal computer,server or other computer system.

Application lifecycle management software delivers different models andtool environments for models to customers and partners for use inmanaging enterprise application software implementing customerprocesses. Customers and partners can extend the provided models totheir needs in client dependent extensions to the models. Manyextensions to the same model may cause inconsistencies that may beavoided via extension priorities. If several extensions are used withinone client, priorities may be used to uniquely calculate the correctmodel. for example, in one extension the “process step” object type isexcluded, in another one it is included. Via the priority it can now bedecided which of the two extension will “win”. Different models andextensions are possible due to the client concept that allowsclient-specific extensions. The priorities allow many customers to workwith different models in the same system. The system may be provided ina stand alone or cloud-based environment. An activation tag may beprovided for each extension, facilitating activation of differentextensions in the same model for different clients.

A core model is provided that serves as the basis for other models.Instances that are derived from the core model are transferrable toinstances based on other models. Thus, the other models are defined asvariations of the core model so that it is possible to transfer instancedata from one instance to another that are based on different modelsduring the lifecycle of instances. For each model, differentfunctionality may be provided. Therefore, the models are bound toenvironments that are used to provide desired features. In addition, anoption to include non-core model based environments may be provided viaexternal environments.

For each model, customer or partner specific extensions may be defined.The extensions may be client specific so that each client may providedifferent models for end users. Since the same model can have severalextensions, a priority for the extensions is used to uniquely calculatea customer model.

Application lifecycle management software can deliver different modelsand tool environments for the models to customers and partners. Thecustomers and partners can then extend the provided models to theirneeds in client dependent extensions. Many extensions to the same modelmay cause inconsistencies that are avoided via extension priorities.Thus, many customers can work with different models in the same system.

FIG. 1 is a block diagram of a life cycle model 100 of a process objectin an example embodiment. A unified directory model based approach isused to model customer processes. The model may be changed viaextensions by customers, yet still retain the ability to managedifferent versions of the objects associated with a life cycle ofobjects in the model. The model based directory facilitates managementof process structures and associated content, such as documents andexecutables and other content during the lifecycle of the processes. Indifferent phases of the lifecycle, variations of the model may be usedsince different content may be maintained. Main parts of the content aremanaged consistently through different lifecycle phases.

Life cycle model 100 shows different versions of a process existingduring different portions of the lifecycle of processes. A businessprocess repository (BPR) 110 is a pre-model implementation of a businessprocess object. While it may not be part of the model in someembodiments, it is a predecessor of a model object. During a lifecycle,a BPR 110 object may change, or a new version of a BPR object might bedelivered. Thus, a model object may be compared against its BPRpredecessor object.

A customer process directory (CPD) object 115 is a design stage object.It is used to build a project and solution directory (PSD) object 120,and also a production version of the PSD object 125, which operates inthe customer production environment. Finally, indicated at 130 is anupgraded version of the PSD object that is optimized.

FIG. 2 illustrates a core model generally at 200. Group object types areillustrated at 210. There are several group object types, includingbusiness functions, configuration structure, configuration, development,documentation, executables, interface scenarios, service messages,project/solution administration, requirements, end user roles andscenario group 215. Several group object types associated with thescenario group object type are illustrated at 220 within scenario group215. The scenario object types track closely with the group object typesin some embodiment. Other group objects may similarly have severaldifferent object types which are not shown. Several group object typesassociated with a scenario object type 225 are illustrated at 235, andinclude for example business functions, configuration, development,documentation executables, service messages, etc. Each scenario hasprocesses assigned. In CPD for example, it is also possible to maintainprocesses in folders in parallel to scenarios.

To be able to copy process content that is based on a CPD model to thecore model for use during lifecycle of the content, certaincompatibility criteria are ensured by defining a common model kernel.The core model is defined that is the basis for all other models.Instances that are derived from the core model may be transferrable toall other models. Thus, other models are defined as variations of thecore model.

FIG. 3 is a block diagram illustration of core model 300 relationshipswith a CPD model 310 and a TMD model 315. For each model, differentfunctionality may be provided. The models in one embodiment are bound toa core environment 320 that is used to provide desired features. Inaddition, an option to include non-core model based externalenvironments 325 into lifecycle management 330 is provided via externalenvironments 325. The core environment serves as a connecting partbetween the models 300, 310, 315 and provide functions for the modelsand lifecycle management 330.

In the external environment 325, a BPR environment 327 is provided. Itprovides for BPR objects which are not part of the core model directory,but may be predecessors of the core model objects. During the lifecycle,a BPR object might change or a new version of a BPR object might bedelivered. Thus, it is possible to compare a core object against it BPRpredecessor object.

The core environment 320 in one embodiment contains a CPD environment335, TMD environment 340, and PSD environment 345. CPD environment 335is based on a separate model in one embodiment so that it is possible toorganize the CPD objects in a different way than objects of a project orsolution. TMD objects are based on a separate model in one embodiment tomirror the differences to a normal implementation. Templates may bemaintained and assigned in this environment. PSD environment 345 isbased on the core model 300 that is the basis of all directory models.CPD and TMD are variations of the core model.

Core environments 320 that are based on core directory models have acorresponding assignment so that it is clear which functionality isneeded. External environments 325 may not be based on a core directorymodel (e.g. BPR). In this case, a mapping to the core directory model isused so that it is possible to transfer objects from those externalenvironments to core directory model-based environments. Further modelsand environments may be defined and integrated, such as for example atest environment with a test model.

The following example illustrated at 400 in FIG. 4 shows howenvironments and models may be used to support a flexible lifecyclemanagement. It is similar to the life cycle model 100 with a versioncontainer from FIG. 3 added. Like components are consistently numbered.A PSD test model 410 has been added. Each box in the lifecycle model 400in the lower portion of FIG. 4 represents an option to manage a version410 of an object within the box. Thus the figure shows an option tomanage an additional “test version” of the object that is managed in aPSD environment.

Since many customers have their own process structure, customers areallowed to make extensions to the core directory models withoutcontradicting the lifecycle management aspects. Therefore, customerextensions may be limited to fit into the core directorymodel/environment concept without compromising the needed flexibility.An extension methodology allows changing the core directory models byexcluding the relation between an object type and an attribute type,excluding the relation between an object type and another object type,adding new object types and attribute types, adding the relation betweenan object type and an attribute type, and adding the relation between anobject type and another object type. In one embodiment, key fields thatare used by lifecycle management may not be changed.

A model extension is defined for a core directory model. Thus, anextension of the core model has an impact on all models; whereas; anextension of one of the other models has an impact on the correspondingmodel. This ensures that the lifecycle management will work forextensions of Core model objects.

For one model, several extensions may exist. A partner may define anextension of the core model and a customer may further add someadditional extensions to the Core model. In such a case, a priority forthe extensions may be defined so that it is possible to calculate thecorrect model including all extensions.

Since it might be desired to have different versions of one model in onesystem (e.g. because different departments or customers work within onesystem with different requirements), the extension can be switched onand off per client.

FIG. 5 illustrates such model extensions at 500. Like components aresimilar numbered as in previous figures. Two extensions are availablefor the core 300 and the CPD model 310. Extension A and Extension X aredefined at 510 and 515 for client 520. The two other extensions 525, 530are applied in client 535. This concept may be used in a cloud-basedenvironment so that it is possible to host different customers withdifferent models in one system.

An excerpt from a top level of an example core directory model isillustrated at 600 in FIG. 6A. On the top level, the core directorymodel consists of 3 sub-structures, a Configuration Structure 610,Interface Scenarios 615, and Scenarios 620. In addition,Project/Solution Administration 625 provides standards (e.g. statusvalues and document templates).

A scenario substructure is illustrated at 630 in FIG. 6B. The scenariosub-structure 630 consists of structure group nodes 632, 634, 636 andstructures nodes 640, 642, 644. In the model, a sender/receivercardinality is used to describe that a scenario group 632 consists of alist of scenarios as shown at 650 in FIG. 6C. This is maintained as asender/receiver cardinality. Within a scenario there exists a list ofprocesses with process steps 644 as shown at 660 in FIG. 6D.Sender/receiver cardinality may also be referred to as a parent/childrelationship.

Object type and attribute type relations in the core directory model areillustrated at 670 in FIG. 6E. Each object type 672, a scenario in thiscase, can have several attribute types 674 assigned with a cardinality676 that determines how many attributes can be associated on instancelevel. For example, a scenario has exactly one description 678 and canhave a list of countries assigned.

FIGS. 7A and 7B illustrate a customer extension to the core directorymodel. On the top level 700, parts of the core directory model arehidden. For example, the scenario group (SCNGRP) object type with allsub-nodes is hidden.

Instead a new top level CPD Folder (CPDFOLDERGRP) at 710 is introduced.The CPD Folder structure is shown in further detail at 715 in FIG. 7B.The structure provides for organization of Master Data (MADA) 720,Organizational Units (ORGUNT) 725 and Processes (PROC) 730 in a folderstructure with arbitrary depth. In one embodiment, a folder can againhave a folder as a sub-node.

FIG. 8 is a graphical interface illustrating a sample instance at 800that is based on the core model. Four levels are illustrated, a toplevel 810 with Scenarios 812 selected, the corresponding scenario level815, with Field Quotation and Ord . . . 817 selected, the correspondingprocess level 820 showing processes associated with the selectedscenario, and a process step level 825 indicating processes stepsassociated with a selection of quotation processing with CRM mobilesites at 830 from process level 820. General attributes of quotationprocessing with CRM model sites 830 are illustrated at 835, including adescription and a checkbox for indicating if it is out of scope. Generalattributes of structuring nodes 840 are also provided, as well as acountries and industries section 845 to identify country IDs andindustry IDs. At 850, objects belonging to quotation processing with CRMmobile sites are listed by group, name, editing constructs and types.

FIG. 9 is an example interface illustrating a sample instance that isbased on a CPD model at 900. The model 900 includes a top level 910,scenario folder level 915, scenario sub-folder level 920, and processlevel 925. The top level 910 illustrates a selected scenario folder 930,resulting in folders 932, 933, and 934 being displayed in the scenariofolder level. Scenario Folder A at 932 is shown as selected, resultingin three scenarios 942, 943, and 944 being shown in the scenariosub-folder level 920. Scenario A1 at 942 is shown as selected, resultingin process 950 being displayed in the process level 925.

FIG. 10 illustrates a user interface displaying a representation of anextension 1000 of the core directory model. An extension ID,MV_CORE_EXT_(—)1, is illustrated at 1005. With this extension, it ispossible to enhance the structure by one level underneath the processstep. Z_FUNCTION_GRP 1010 is introduced as a sub-node of PROCSTEP 1015.Each Z_FUNCTION_GRP is associated with a list of Z_FUNCTION. Thus, on aninstance level, each process step can have a list of functionsunderneath. A user is given the option to exclude sub-nodes from theselected model via checkboxes 1020.

FIG. 11 is a sample instance 1100 based on the extensionMV_CORE_EXT_(—)1 of the core directory model. Instance 1100 illustratesa top level 1110 with a scenario 1112 selected. A scenario level 1115shows several different scenarios with a field account and cont . . .1117 selected. A process level 1120 shows an account processing in . . .1122 selected, resulting in a process step level 1125 illustratingseveral process steps with Print account overview 1127 selected. Afurther level 1130 has been added to provide a list of functionsassociated with a selected process step. In this instance, Function A1at 1132 is shown. A list of functions is now available under processstep, which was previously the lowest level.

FIG. 12 is an interface 1200 illustrating activation and layering ofextensions. Extensions are listed by extension ID 1210. An extension isactivated by removing an activation flag 1215 by means of a checkbox.This flag activates the extensions in the selected client (tenant).Therefore, it is possible to activate different extensions for the samemodel in different clients. Thus, the same system can mange differentcore models based on the activations of the extensions in thecorresponding clients.

In one embodiment, there can be several extensions for the same model inthe same client. One example includes when a partner makes an extensionfor the core model and a customer also makes an extension for the coremodel on top of the partner extension. In this case, a priority 1220 maybe defined for the extensions so that the final model may be uniquelydetermined.

FIG. 13 illustrates an example extension for an object type-attributetype relation at 1300. Two attribute types AVGDAY 1310 and AVGHOUR 1320are excluded from object type scenario (SCN) as indicated at check boxes1325, 1330. Two new attribute types (ORGAREA 1335, ROLEID 1340) areadded to SCN. Such extensions may be defined as model independent, wherethe extension is valid for all models, or may be model specific, suchthat the extension is valid for a selected model. In general, thefunctionality is similar to the object-object type extensions, includingpriority, exclude, client-dependency, etc. The exclude flag within amodel provides an option to “hide” an existing relation, providing theability to remove such relations from the model.

FIG. 14 illustrates an model extension with a major structure change at1400. With this extension, a new level for sub-scenarios is insertedbetween scenarios and processes and the process group is movedunderneath the sub-scenarios. Object type PROCGRP 1410 is excluded at1415 as a child node of scenario (SCN). A new group for sub-scenarios(SUB_SCNGRP 1420) is inserted as a new child node of scenario (SCN) thathas sub-scenarios as child nodes (SUB_SCN 1425). Underneath thesub-scenario object type the process group object type (PROCGRP 1430) isinserted.

In some embodiments, parts of the model may be protected. In oneembodiment, an object type-object type relation or object type-attributetype relation may be protected. Such protection ensure that certainparts of the model may not be changed.

FIG. 15 is a block diagram of a computer system to facilitate modelcreation and lifecycle management aspects according to exampleembodiments. In the embodiment shown in FIG. 15, a hardware andoperating environment is provided that is applicable to any of themodels and interfaces shown in the other Figures. In some embodiments,the computer system may be implemented in a cloud based environment withresources assigned as needed.

As shown in FIG. 15, one embodiment of the hardware and operatingenvironment includes a general purpose computing device in the form of acomputer 1500 (e.g., a personal computer, workstation, or server),including one or more processing units 1521, a system memory 1522, and asystem bus 1523 that operatively couples various system componentsincluding the system memory 1522 to the processing unit 1521. There maybe only one or there may be more than one processing unit 1521, suchthat the processor of computer 1500 comprises a singlecentral-processing unit (CPU), or a plurality of processing units,commonly referred to as a multiprocessor or parallel-processorenvironment. In various embodiments, computer 1500 is a conventionalcomputer, a distributed computer, or any other type of computer.

The system bus 1523 can be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memorycan also be referred to as simply the memory, and, in some embodiments,includes read-only memory (ROM) 1524 and random-access memory (RAM)1525. A basic input/output system (BIOS) program 1526, containing thebasic routines that help to transfer information between elements withinthe computer 1500, such as during the start-up, may be stored in ROM1524. The computer 1500 further includes a hard disk drive 1527 forreading from and writing to a hard disk, not show, a magnetic disk drive1528 for reading from or writing to a removable magnetic disk 1529, andan optical disk drive 1530 for reading from or writing to a removableoptical disk 1531 such as a CD ROM or other optical media.

The hard disk drive 1527, magnetic disk drive 1528, and optical diskdrive 1530 couple with a hard disk drive interface 1532, a magnetic diskdrive interface 1533, and an optical disk drive interface 1534,respectively. The drives and their associated computer-readable mediaprovide non volatile storage of computer-readable instructions, datastructures, program modules and other data for the computer 1500. Itshould be appreciated by those skilled in the art that any type ofcomputer-readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random access memories (RAMs), read onlymemories (ROMs), redundant arrays of independent disks (e.g., RAIDstorage devices) and the like, can be used in the exemplary operatingenvironment.

A plurality of program modules can be stored on the hard disk, magneticdisk 1529, optical disk 1531, ROM 1524, or RAM 1525, including anoperating system 1535, one or more application programs 1536, otherprogram modules 1537, and program data 1538. Programming forimplementing one or more processes or method described herein may beresident on any one or number of these computer-readable media.

A user may enter commands and information into computer 1500 throughinput devices such as a keyboard 1540 and pointing device 1542. Otherinput devices (not shown) can include a microphone, joystick, game pad,satellite dish, scanner, or the like. These other input devices areoften connected to the processing unit 1521 through a serial portinterface 1546 that is coupled to the system bus 1523, but can beconnected by other interfaces, such as a parallel port, game port, or auniversal serial bus (USB). A monitor 1547 or other type of displaydevice can also be connected to the system bus 1523 via an interface,such as a video adapter 1548. The monitor 1547 can display a graphicaluser interface for the user. In addition to the monitor 1547, computerstypically include other peripheral output devices (not shown), such asspeakers and printers.

The computer 1500 may operated in a networked environment using logicalconnections to one or more remote computers or servers, such as remotecomputer 1549. These logical connections are achieved by a communicationdevice coupled to or a part of the computer 1500; the invention is notlimited to a particular type of communications device. The remotecomputer 1549 can be another computer, a server, a router, a network PC,a client, a peer device or other common network node, and typicallyincludes many or all of the elements described above I/O relative to thecomputer 1500, although only a memory storage device 1550 has beenillustrated. The logical connections depicted in FIG. 15 include a localarea network (LAN) 1551 and/or a wide area network (WAN) 1552. Suchnetworking environments are commonplace in office networks,enterprise-wide computer networks, intranets and the internet, which areall types of networks.

When used in a LAN-networking environment, the computer 1500 isconnected to the LAN 1551 through a network interface or adapter 1553,which is one type of communications device. In some embodiments, whenused in a WAN-networking environment, the computer 1500 typicallyincludes a modem 1554 (another type of communications device) or anyother type of communications device, e.g., a wireless transceiver, forestablishing communications over the wide-area network 1552, such as theinternet. The modem 1554, which may be internal or external, isconnected to the system bus 1523 via the serial port interface 1546. Ina networked environment, program modules depicted relative to thecomputer 1500 can be stored in the remote memory storage device 1550 ofremote computer, or server 1549. It is appreciated that the networkconnections shown are exemplary and other means of, and communicationsdevices for, establishing a communications link between the computersmay be used including hybrid fiber-coax connections, T1-T3 lines, DSL's,OC-3 and/or OC-12, TCP/IP, microwave, wireless application protocol, andany other electronic media through any suitable switches, routers,outlets and power lines, as the same are known and understood by one ofordinary skill in the art.

EXAMPLES Example 1

A computer readable storage device having a data structure storedthereon, the data structure comprising:

-   -   a core directory model having a top level, and successive        scenario level, process level, and process step level; and    -   an extension to add a sub-node level beneath the process step        level, the sub-node level identifying a sender object type, a        receiver object type, a cardinality, and an activation flag to        activate selected extensions in the sub-node level.

Example 2

The storage device of example 1 wherein the data structure furthercomprises a design stage directory model and a production stagedirectory model, each derived from the core directory model.

Example 3

The storage device of any of examples 1-2 wherein the design stagedirectory model and the production state directory model each complywith selected compatibility criteria to facilitate transfer of instancesbased on different models between instances.

Example 4

The storage device of any of examples 1-3 and further comprising anexternal environment to facilitate use of a business process model thatis not derived solely from the core directory model.

Example 5

The storage device of any of examples 1-4 and further comprising a coreenvironment to maintain and assign templates to the design stagedirectory model and production stage directory model.

Example 6

The storage device of any of examples 1-5 wherein the production stagedirectory model supports a build stage, productive stage, and upgradestage.

Example 7

The storage device of any of examples 1-6 wherein an extension comprisesan a additional version of an object managed in a production stageenvironment.

Example 8

The storage device of any of examples 1-7 wherein the data structurefurther comprises how a list of scenarios in a scenario group is definedin a model including a sender/receiver cardinality for each scenario inthe list of scenarios.

Example 9

The storage device of any of examples 1-8 wherein the data structurefurther comprises object types, with an object type having severalattribute types with a cardinality that determines how many attributesare associated on an object instance level.

Example 10

The storage device of any of examples 1-9 wherein the data structurefurther comprises a top level folder extension to a design stagedirectory model to facilitate organization of master data and processesin a folder structure with arbitrary depth.

Example 11

The storage device of any of examples 1-10 wherein an instance based onthe core directory model includes a top level, a scenario level, aprocess level, and a process step level, and wherein an extension to thecore directory model adds a list of functions in a level below theprocess step level.

Example 12

The storage device of any of examples 1-11 wherein the data structurefurther comprises a design stage directory model derived from the coredirectory model, the design stage directory model including a top level,a scenario folder level, a scenario sub-folder level and a processlevel.

Example 13

A method comprising:

-   -   deriving a design stage directory model based an a core        directory model via a specifically programmed computer        processor;    -   deriving a production stage directory model based on the core        directory model via the specifically programmed computer        processor;    -   adding an extension to one of the models including an activation        flag to activate the extension; and    -   saving the models and extension to a computer readable storage        device.

Example 14

The method of example 13 wherein the design stage directory model andthe production state directory model each comply with selectedcompatibility criteria to facilitate transfer of instances derived fromthe core directory model between instances based on the two models.

Example 15

The method of any of examples 13-14 wherein the production stagedirectory model supports a build stage, productive stage, and upgradestage.

Example 16

The method of any of examples 13-15 and further comprising:

-   -   using the computer to generate an external environment to        facilitate use of a business process model that is not derived        solely from the core directory model; and    -   using the computer to generate a core environment to maintain        and assign templates to the design stage directory model and        production stage directory model.

Example 17

A system comprising:

-   -   a programmed computer system having a module to provide an        extension to a core directory model, the core directory model        having a top level, and successive scenario level, process        level, and process step level, wherein the extension adds a        sub-node level beneath the process step level;    -   the programmed computer system further having a module to        provide an extension to a design stage directory model and a        production stage directory model, each derived from the core        directory model and complying with selected compatibility        criteria to facilitate transfer of instances derived from the        core directory model between instances based on different        models.

Example 18

The system of example 17 wherein the programmed computer systemcomprises computing resources in a cloud based computing environment.

Example 19

The system of any of examples 17-18 wherein an extension includes anactivation flag to activate selected extensions.

Example 20

The system of any of examples 17-20 wherein an extension includes anadditional version of an object managed in a production stageenvironment.

Although a few embodiments have been described in detail above, othermodifications are possible. For example, the logic flows depicted in thefigures do not require the particular order shown, or sequential order,to achieve desirable results. Other steps may be provided, or steps maybe eliminated, from the described flows, and other components may beadded to, or removed from, the described systems. Other embodiments maybe within the scope of the following claims.

1. A computer readable storage device having a data structure storedthereon, the data structure comprising: a core directory model having atop level, and successive scenario level, process level, and processstep level; and an extension to add a sub-node level beneath the processstep level, the sub-node level identifying a sender object type, areceiver object type, a cardinality, and an activation flag to activateselected extensions in the sub-node level.
 2. The storage device ofclaim 1 wherein the data structure further comprises a design stagedirectory model and a production stage directory model, each derivedfrom the core directory model.
 3. The storage device of claim 2 whereinthe design stage directory model and the production state directorymodel each comply with selected compatibility criteria to facilitatetransfer of instances based on different models between instances. 4.The storage device of claim 2 and further comprising an externalenvironment to facilitate use of a business process model that is notderived solely from the core directory model.
 5. The storage device ofclaim 4 and further comprising a core environment to maintain and assigntemplates to the design stage directory model and production stagedirectory model.
 6. The storage device of claim 2 wherein the productionstage directory model supports a build stage, productive stage, andupgrade stage.
 7. The storage device of claim 6 wherein an extensioncomprises an additional version of an object managed in a productionstage environment.
 8. The storage device of claim 1 wherein the datastructure further comprises how a list of scenarios in a scenario groupis defined in a model including a sender/receiver cardinality for eachscenario in the list of scenarios.
 9. The storage device of claim 1wherein the data structure further comprises object types, with anobject type having several attribute types with a cardinality thatdetermines how many attributes are associated on an object instancelevel.
 10. The storage device of claim 2 wherein the data structurefurther comprises a top level folder extension to a design stagedirectory model to facilitate organization of master data and processesin a folder structure with arbitrary depth.
 11. The storage device ofclaim 1 wherein an instance based on the core directory model includes atop level, a scenario level, a process level, and a process step level,and wherein an extension to the core directory model adds a list offunctions in a level below the process step level.
 12. The storagedevice of claim 1 wherein the data structure further comprises a designstage directory model derived from the core directory model, the designstage directory model including a top level, a scenario folder level, ascenario sub-folder level, and a process level.
 13. A method comprising:deriving a design stage directory model based on a core directory modelvia a specifically programmed computer processor; deriving a productionstage directory model based on the core directory model via thespecifically programmed computer processor; adding an extension to oneof the models including an activation flag to activate the extension;and saving the models and extension to a computer readable storagedevice.
 14. The method of claim 13 wherein the design stage directorymodel and the production state directory model each comply with selectedcompatibility criteria to facilitate transfer of instances derived fromthe core directory model between instances based on the two models. 15.The method of claim 14 wherein the production stage directory modelsupports a build stage, productive stage, and upgrade stage.
 16. Themethod of claim 13 and further comprising: using the computer togenerate an external environment to facilitate use of a business processmodel that is not derived solely from the core directory model; andusing the computer to generate a core environment to maintain and assigntemplates to the design stage directory model and production stagedirectory model.
 17. A system comprising: a programmed computer systemhaving a module to provide an extension to a core directory model, thecore directory model having a top level, and successive scenario level,process level, and process step level, wherein the extension adds asub-node level beneath the process step level; the programmed computersystem further having a module to provide an extension to a design stagedirectory model and a production stage directory model, each derivedfrom the core directory model and complying with selected compatibilitycriteria to facilitate transfer of instances derived from the coredirectory model between instances based on different models.
 18. Thesystem of claim 17 wherein the programmed computer system comprisescomputing resources in a cloud based computing environment.
 19. Thesystem of claim 17 wherein an extension includes an activation flag toactivate selected extensions.
 20. The system of claim 17 wherein anextension includes an additional version of an object managed in aproduction stage environment.